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Abstract 

A cost effective introduction of software reuse tech- 
niques requires the reuse of existing software developed 
in many cases without aiming at reusability . This pa- 
per discusses the problems related to the analysis and 
reengineering of exisJtn^ software in order to reuse it. 
We introduce a process model for component extrac- 
tion and focus on the problem of analyzing and qual- 
ifying software components which are candidates for 
reuse. A prototype tool for supporting the extraction 
of reusable components is presented. One of the com- 
ponents of this tool aids in understanding programs 
and is based on the functional model of correctness. 
It can assist software engineers in the process of find- 
ing correct formal specifications for programs. A de- 
tailed description of this component and an example to 
demonstrate a possible operational scenario are given. 

1 Introduction 

Successful reuse of software resources can in- 
crease the overall quality and productivity in software 
projects by a large factor. Some of the problems that 
still limit software reuse are: 

1. The difficulty of understanding a given software 
product in the absence of its original developers. 

2. The scarce availability of reusable objects, even 
though there is a tremendous amount of available 
software. 

3. The difficulty of retrieving, from a large data 
base, software components which can best match 
the given semantics requirements. 

4. The lack of extraction and adaptation techniques 
that facilitate the reuse process. 


New process models for software development 
should substitute the existing ones that are not de- 
fined to benefit from or support reuse. These new 
models should take advantage of reuse, introduce more 
reusable resources, and overcome the existing prob- 
lems that limit reuse. 

Developing reusable components is generally more 
expensive than developing specialized code, because 
of the overhead of designing for reusability and main- 
taining the component repository. A rich and well- 
organized catalog of reusable components is the key 
to a successful component repository and a long term 
economic gain. Moreover, such a catalog will not be 
available to an organization unless it can reuse the 
same code it developed in the past. Mature applica- 
tion domains, where most of the functions that need to 
be used already exist in some form in earlier systems, 
should provide enough components for code reuse. For 
example, Lanergan and Grasso found rates of reuse of 
about 60% in business applications^]. A technique 
for extracting reusable components can improve pro- 
ductivity since it provides the software developer with 
components that are ready for reuse or need minor 
adaptation. Moreover, it can improve the software 
quality as it helps in better understanding these com- 
ponents during the extraction process. 

In this paper, we use a process model[2] that serves 
not only to enhance the development of the project 
under consideration but also to organize and plan for 
better reuse technology in future projects. This model 
splits the traditional life-cycle model into two separate 
organizations, the project organization and the expe- 
rience factory. In this framework we introduce a pro- 
cess model for component extraction and focus on the 
problem of qualifying candidate software components 
for reuse. 

A prototype tool constituting one of the elements 
of an integrated system for extracting reusable compo- 
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nents is described. This prototype tool helps in under- 
standing programs by deriving their specifications and 
is based on the functional model of correctness[3 , 4]. 
The tool could be applied to program fragments as 
well as to complete programs and it helps in simul- 
taneously checking syntax, static semantics, and gen- 
erating specifications. We conclude the paper with 
an example to demonstrate a possible operational see- 
nario of the tool. 


2 Organizing the component extrac- 
tion 

Currently, all reuse occurs in the project develop- 
ment, where there is a completion deadline and the 
top priority is to deliver the system on time. This 
makes the objective of developing reusable software, 
at best, a secondary concern. Besides, project person- 
nel cannot recognize the pieces of software appropriate 
for other projects. 

We make use of a reuse-oriented model based on 
two separate organizations^]: 

• The project organization: Its goal is to deliver 
the systems required by the customer. The pro- 
cess model can be chosen based upon the charac- 
teristics of the application domain, taking advan- 
tage of prior software products and experience. 

• The experience factory: It supports project 
development by analyzing and synthesizing all 
kinds of experience, acting as a repository for such 
experience, and supplying that experience to var- 
ious projects on demand. Within the experience 
factory, we can identify various sub-organizations. 
One of them is the component factory which 
develops reusable components, extracts reusable 
components from existing systems, and general- 
izes or remodels any previously produced compo- 
nent. 

Different conceptual architectures can be used for 
the component factory [5]. At one extreme there is the 
clustered architecture in which all software develop- 
ment activities are concentrated in the project organi- 
zation and the component factory is dedicated only to 
processing already existing software. At the other ex- 
treme there is the detached architecture in which the 
development activities are concentrated in the com- 
ponent factory and the project organization performs 
only high-level design and integration. The clustered 


architecture is much closer to the way software is cur- 
rently implemented. The development of the compo- 
nents is probably faster in the project organization 
since there is less communication overhead and more 
direct pressure for their delivery. On the other hand, 
the components developed are more context depen- 
dent. In the detached architecture, there is more em- 
phasis on developing general purpose components in 
order to serve several project organizations more ef- 
ficiently. On the other hand, there are more chances 
for bottlenecks and for periods of inactivity due to the 
lack of requests from the projects. The detached ar- 
chitecture is probably better suited for environments 
where the practice of reuse is formalized and mature. 
An organization that is just starting with reuse should 
probably instantiate its component factory using the 
clustered architecture and then, when it reaches a suf- 
ficient level of maturity and improvement with this 
architecture, start implementing the detached archi- 
tecture in order to continue the improvement. 

In any case, the extraction of reusable components 
is a characteristic activity of the component factory. 
The next section will present in detail the features of 
this activity, in the framework of a component fac- 
tory. Caldiera and Basili[6] have proposed a process 
model for the extraction of reusable components in 
two phases: the identification phase and the quali- 
fication phase (see figure 1). The necessary human 
intervention in the second phase is the main reason 
for splitting the process in two steps. The first phase, 
which can be fully automated, reduces the amount of 
expensive human analysis needed in the second phase 
by limiting analysis only to components that really 
look worth considering. 


3 The extraction process 
3.1 Identification 

Program units are automatically extracted and 
made to be independent compilation units. These in- 
dependent units are measured according to observable 
properties related to their potential for reuse in three 
steps. These steps are summarized here: 

1. Definition of the reusability attribute model: 
A set of automatable measures that captures the char- 
acteristics of potentially reusable components is de- 
fined along with acceptable ranges of values for these 
metrics. 

2. Extraction of components: Modular units (e.g. 
C functions. Ada subprograms or blocks, or Fortran 
subroutines) are extracted from existing software and 
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completed so that they have all the external references 
needed to reuse them independently. 

3. Application of the model: The current reusabil- 
ity attribute model is applied to the extracted, com- 
pleted components. Components whose measures are 
within the model's range of acceptable values become 
candidate reusable components to be analyzed in the 
qualification phase. 

A detailed description of the component identifica- 
tion phase, a definition of a basic reusability attribute 
model, and an application of this model on several 
case studies using a computer-based system have al- 
ready been discussed in the literature[6]. 



Figure 1: Component extraction. 

3.2 Qualification 

The extracted components are analyzed in order 
to understand them and record their meaning. The 
components are packaged by associating with them a 
reuse specification, a significant set of test cases, a set 
of attributes based on a reuse classification scheme, 
and a set of procedures for reusing the component. 
This phase consists of following steps: 

1. Formal specification: A precise description of 
what the component does is generated and some as- 
surance is obtained that the component meets the re- 
quirements. 

Since formal specifications are based on mathemat- 
ical notations, they help in understanding the soft- 
ware by removing the ambiguities which might be in- 
troduced by any informal notation. Formal specifi- 
cations are different from the programs they specify 
since they only express the behavior of the program 


without stating how the program derives this behav- 
ior. So, formal specifications are the basis for selecting 
and storing software components as they improve un- 
derstandability and assist in producing more reliable 
and higher quality software. Since the specification of 
complex tasks may in itself be complex, the process 
of specification construction must be formalized and 
supported by automated tools. In the next section, we 
will describe a prototype tool that aids in understand- 
ing programs. This tool provides automated support 
for deriving the functional specifications of programs 
and proving their partial correctness. In other words, 
it helps in proving that the program is consistent with 
its specification but does not prove its termination. 

Formally specifying a software component and 
proving its partial correctness do not mean that the 
component will pass this step. There are several other 
properties that should exist in the candidate compo- 
nents for the sake of understandability. We must not 
ignore other important features such as proper docu- 
mentation, use of meaningful variable names, and the 
structured style of programming. The informal infor- 
mation that the software engineer deals with cannot be 
ignored relying on the fact that the automated spec- 
ifications tools will supplement those features. The 
informal information is important in explaining some 
intuitive ideas that are hard to explain using formal 
specifications. 

Since we need both formal and informal informa- 
tion, a domain expert is needed to perform the specifi- 
cation step. This expert extracts the formal specifica- 
tion of each candidate reusable component, assisted by 
the automated tools available, and examines the other 
informal features that cannot be judged using auto- 
mated tools. Components that are not relevant, not 
correct, or whose functional specification is not easy 
to extract are discarded. The expert reports reasons 
for discarding candidates and other insights that will 
be used to improve the reusability attributes model. 
2. Testing: Test cases are generated, executed and 
associated with components. Deriving the functional 
specification and proving the correctness of a pro- 
gram do not mean that it will not fail when compiled 
and/or executed. This might simply be due to the 
fact that termination of the program has not been 
proven. Moreover, in most verification and specifica- 
tion systems, arithmetic operations ignore things such 
as overflow, underflow, and round-off errors. 

Testing can take advantage of the functional spec- 
ification generated by performing functional testing. 
Also, structural testing can be done using a cover- 
age analyzer. If, as is likely, the component needs a 
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‘wrapping’ to be executed, the testing step generates 
this wrapping. If a component passes the testing then 
test cues, wrapping, and test results are stored in the 
component repository. Components that do not sat- 
isfy the test are discarded. Again, the reasons for dis- 
carding candidates are recorded and used to improve 
the reusability attributes model and possibly the pro- 
cess for extracting the functional specification. This 
is most likely the last step at which a component will 
be discarded. 

3. Packaging: The extracted candidates are stored 
in the component repository along with their func- 
tional specifications and test cases. The component 
repository is actually a data base of experience in 
which information on software products, processes, 
and measures of aspects of them is stored. That is 
why we organize this data base by classifying both the 
reusable components and their development histories 
according to several domain dependent criteria. 

Information for the future reuser is provided in a 
manual that contains a description of the component’s 
function and interfaces as identified during generation 
of its functional specification, directions on how to in- 
stall and use it, information about its procurement 
and support, and information for component mainte- 
nance. 

At the end of each process cycle the reusability at- 
tribute model is updated by drawing on information 
from the qualification phase to add more measures, 
modify or remove measures that proved ineffective, or 
alter the range of acceptable values. This step requires 
analysis and possibly even further experimentation. 
The taxonomy is updated by adding new attributes 
or modifying the existing ones according to problems 
reported by the experts who classify the components. 


4 The CARE system 
4.1 Overview 

The CARE[6] system(CARE l : Computer Aided 
Reuse Engineering) has been designed to support the 
proposed process model for extracting reusable com- 
ponents. As shown in figure 2, it consists of two main 
subparts: the component identifier and the component 
qualifier. The component identifier consists of the 
model editor, which helps in defining and modifying 
the reusability attributes model, and the component 
extractor which applies such model to the programs. 

1 The CARE system is under development at the Computer 
Science Department of the University of Maryland 


The component qualifier consists of the specifier, the 
tester, and the packager. The current version of the 
CARE system consists of the component extractor and 
the specifier. It runs on a Sun Workstation and sup- 
ports ANSI C and Ada. In the rest of this section we 
focus on the description of the specifier. 


* COMPONENT 
IDENTIFIER 

^ COMPONENT 
QUALIFIER 

1.1 

MODEL EDITOR 

2.1 

SPECIFIER 

2.2 

TESTER 

1.2 

COMPONENT 

EXTRACTOR 

2.3 

PACKAGER 



Figure 2: CARE system architecture. 

4.2 The component specification tool 

The prototype specifier included in the CARE tool 
is the second in a series of prototype tools developed at 
the Computer Science Department of the University of 
Maryland under the general name FSQ, for Functional 
Specification Qualifier. This prototype supports the 
derivation of programs specifications and the verifica- 
tion of whether or not the programs meet those spec- 
ifications. It does not only help to specify and check 
the partial correctness of finished programs, but it also 
works on unfinished programs and program fragments. 
It is a program understanding tool that is based on 
a formal specification technique. CARE-FSQ 2 uses 
Mills’ functional model of correctness[3, 4] in order to 
derive the specifications. This model requires the user 
to provide only the loop function and then a technique 
is provided to derive the program specification. Other 
techniques[7, 8] require the user to provide an entry as- 
sertion, an exit assertion, and a loop assertion. Those 
techniques are more useful in verifying that the pro- 
gram is consistent with its specification. The process 
of deriving specifications helps more in understanding 
the software. Moreover, the functional method pro- 
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vides simple and intuitive notations that can be easily 
understood. 

The CARE-FSQ 2 prototype helps in checking syn- 
tax static semantics, and generating specifications at 
the same time. CARE-FSQ 2 also provides the capa- 
bility of carrying out some algebraic simplifications 
and enables the user to make use of some well defined 
mathematical functions in the specification of the loop 
function. 

4.2.1 Formal foundation: Each statement 5 is 
given a meaning as a function from a program state 
to another state. A state is a mapping from the vari- 
able names to their current values. The square bracket 
notation is used to denote the function represented by 
the program construct contained inside the brackets, 

i.e. [5] represents the function computed by the state- 
ment S. We use four basic structures[3, 4]: 

1. Assignment 

The meaning of the assignment v := e, where v is 
a variable and e is an expression, is: 

[v - e] = {(S, T) : T = S except that 

H(T) = [e)(T)} 

We can define the meaning of variables and expres- 
sions as a mapping from a state to a value. 

2. Composition 

If A and B are statements and o is functional com- 
position, we have: 

[A; B] = [-4] o [B] 

3. Alternation 

[if B then S fi ) = {(V, [S\U) : [B](U) = true}U 
{(U,U): [B)(U) = false) 

[if B then S\ else S 2 fi] — {(U, [5i]l/) : (5](t^) 

= true} U (U, [So]U) : [B)(U) = false) 

4. Iteration 

[while B do So<f\ = {( T.U ) : 3k > 0 : VO < i < k ( 
([B]([S]‘(T)) = true A (B]([5]*(T)) = false 
A (S] fc (T) = U)} 

In other words, the loop function is undefined for a 
state T unless there is a natural number k which de- 
notes the number of iterations after which the test first 
fails. T is then transformed to the fc-fold composition 
of S on T. In order to carry out practical proofs, the 


following characterizing theorem is needed[9]. 

Theorem 

Let W be the program fragment while B do S od , 
Then / = [W] if and only if: 

1. domain{f) = domain([W]) 

2. ((B](T) = false) => f(T) = T 

3. / = [if B then S fi) o / 

This theorem provides a method for deriving the 
correct loop function /: 

1. Guess or work out a trial function /. 

2. Use the three conditions of the theorem to check 
that the trial function is correct. 

A trace table can be used to organize the derivation 
of program meanings (by a symbolic execution of the 
program)[4, 9]. 

The strength and weakness of the functional 
method, in comparison with other specification tech- 
niques, originate from the fact that even though exact 
functions state accurately the meaning of a loop, they 
are harder to work with than the weak assertions that 
suffice when there is a loop initialization providing a 
precondition. 

4.2.2 The implementation: CARE-FSQo is im- 
plemented using the Synthesizer Generator[10] and 
Maple, an interactive algebraic symbolic executor[ll]. 
An overview of the tool is shown in figure 3. The 
Synthesizer Generator requires as an input a descrip- 
tion of an attribute grammar and generates from it 
a hybrid language-based editor that allows a combi- 
nation of text editing and structure editing. As the 
user edits program text and annotations, the system 
creates and edits abstract syntax trees that represent 
pieces of programs and their specifications. The at- 
tributes of the nodes of this tree carry information 
about the static semantics of the program as well as 
its specifications, and they are evaluated incremen- 
tally. The basic feature of Maple is its ability to sim- 
plify expressions involving unevaluated elements. As 
each complete statement is entered by the user, it is 
evaluated and the results are printed on the output 
device. Maple enables carrying out algebraic simpli- 
fications during the symbolic execution. In order to 
overcome the limitations of Maple in the evaluation 
of boolean expressions, CARE-FSQ 2 has an interac- 
tive feature that allows the user, before writing the 
specifications, to simplify boolean expressions and the 
expressions containing array notations. 
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Figure 3: Overview of CARE-FSQ 2 - 

In a typical CARE-FSQ 2 session, the user derives 
the specifications of the program using step-wise ab- 
stractions. In other words, the user starts by trying to 
find the correct specification of every loop in the pro- 
gram as a separate entity. After succeeding in this, 
the correct specification of the whole program can be 
found. This methodology of step-wise abstraction en- 
ables the software engineer to concentrate on small 
pieces of code, one at a time, and to mitigate in this 
way the difficulty of specifying the whole program. 

Currently, CARE-FSQ 2 supports a subset of Ada 
with modifications on the input/output mechanism. 
The data types supported are integer, boolean, char- 
acter, a restricted form of floating point, constrained 
arrays, and user defined data types. The basic control 
structures of Ada are supported except unconditional 
‘go to.’ statements, and case statements. Static se- 
mantic checking is also included. A brief description 
of the input/output mechanism and the specification 
language is given in the rest of this subsection. 

Input and output is done through atomic and 
stream ports[12]. A subprogram, called an elementary 
process, accepts input data from input ports, performs 
computation specified with an Ada-like notation, and 
returns results through output ports. The input and 
output of single data items can be carried out through 
atomic ports. Stream ports are used as schemes for 
data types whose elements can be accessed in a linear 
order. The stream ports of one process can be bound 
to particular data types to produce the implementa- 
tion. Input and output ports can be bound to files 
to communicate with the system. This form of data 


abstraction helps in making the specification process 
more general and easier. The following seven opera- 
tions are defined for atomic and stream ports: 

1. Receive(p): To Receive a value via the input port 
p from the source associated with the port. 

2. Send(p): To Send a value via the output port p 
to the destination associated with the port. 

3. Initialize(p): To open the stream associated with 
the stream port p for reading. 

4. Receive(p, v): To receive a value into a variable 
v from the stream associated with the input port 

P- 

5. Send(p, v): To send the value of variable v to the 
stream associated with the output port p. 

6. isEOS(p): A boolean function to check if end of 
stream is reached in the input stream port p. 

7. Finalize(p): To close the stream associated with 
the port p. The effect of finalization for an output 
stream port is that the function isEOS becomes 
true at the consumer process. 

The specifications for CARE-FSQ 2 are written us- 
ing guarded command sets whose syntax is: 

< guarded command set > = 

< guarded command > 

{ | < guarded command >} 

< guarded command > ::= 

< boolean expr > — 

< concurrent assignment > 

< concurrent assignment > = 

< var > := < expr > | < var > , 

< concurrent assignment > , < expr > 

A concurrent assignment is an extension of the assign- 
ment statement where a number of different variables 
can be substituted simultaneously. The concurrent 
assignment statement is denoted by a list of differ- 
ent variables to be substituted at the left hand side 
of the assignment operator and an equally long list of 
expressions as its right hand side. The ith variable 
from the left hand list is to be replaced by the ith ex- 
pression from the right hand list. The expressions can 
include calls to some mathematical functions such as 
min, max, product, sum, factorial, igcd (greatest com- 
mon divisor), irem (remainder), and iquo (quotient). 
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An array is considered to be a partial function from 
subscript values to the type of array elements. The 
command a(i) := e assigns a new function to a, a 
function that is the same as the old one except that at 
the argument i its value is e. The notation (a,t,e) is 
used to denote the array that is the same as a except 
when applied to the value t yields e. The notation 
(a, index = m..n,e) is used to denote the array that 
is the same as a except when applied to index values 
between m and n, i.e. m < index < n, it yields e. The 
expression e can be a function of the bound variable 
index. To make the two notations consistent, (a,i,e) 
is written (a, index = »,«) where index is a bound 
variable. The notation defined for arrays are used for 
stream ports as well. A stream port is treated as an 
array whose subscript is of type integer with the first 
element subscript being one. 



; Kiic 


1: integer; 
V 1: integer; 
integer; 

: integer; 


Recdve(x); 

Recdv«(y); 
x 1 x; 

<trlTe y -> xl, y 1 «*ifi(xl. yD. inin(xi,yl» 
whllcxl /-y 1 loop 
If xl > yl then 
xl xl - 1; 
else 

yl :-yi - 1; 
end If; 
end loop; 
b 1; 

*.V C o'-> s,b :-0.b * roctorlel(s) 

1 . <-0 -> I > 

while s > O loop 
b b * *; 


► 1; 


end loop; 


O 

z :-b; 



Send(z); 


e 



a 

<KO <0 O 

Positions^ *t 




Figure 4: The program to be specified. 

4.2.3 Example: We describe a short example, due 
to the space limitation, to demonstrate a sample re- 
sult obtained using CARE-FSQ?. In order to find the 
correct specification of a while loop, the user should 
annotate it with a trial loop function enclosed between 
two curly braces. CARE-FSQ 2 assists the user in ver- 
ifying the correctness of the loop specification by cal- 
culating the composition [if B then S fi] 0 /■ The 
user, on the other hand, must ensure that the three 
while loop verification conditions are satisfied. After 
verifying all the while loops in the program, the user 


expr * <xl-yl < 0 or yl-xl < yl~xl < 0 

Uould you like to simplify this expression? Cy/nl. y 
Enter the simplified expression; yl < xl 

expr : <xl-yi < 0 or yl-xl < 0) and not yl-xl < 0 
W^d you like to simplify this expression? ty/nl* y 
Enter the simplified expression: yl > xl 

exDr • not (xl-yl < 0 or yl-xl < 0) ^ _ 

Uould* you like to simplify this expression. Cy/n3* y 
the simplified expression; yl - xl 



yl < xl -> 
xl, yl := 
min<xl-l,yl> - 


min(xl-l,yl) 


I 


yl > Xl “> 
xl, yl := 


I 

yl = xl “> 

y ^ ^ y ^ • S 

*ln<xl,yl), ntn<xl,yl> 

Figure 5: Finding the specification of the first loop. 


ayD p ♦ < 0 and — a + l ^ 0 

Uould'you like to simplify this expression? Cy/nl: y 
Enter the simplified expression; a > 1 


IWd : y^ 1 lke*to simplify this expression? Cy/nl: y 
Enter the simplified expression; a = 1 


•vnf* * not -a ^ 0 and a 0 _ r . « 

Would you like to simplify this expression Cy/nl. y 
Enter the simplified expression: a <= 0 


The symbolic execution resul t i s : 


a > 1 -> 

S'. b*GAMMA<a+l> 


a = 1 -> 
a, b : = 
a-1, b*a 


a <= 0 -> 
a, b := 
a, b 

Figure 6: Finding the specification of the second loop. 

can proceed to find the functional meaning of the 
whole program. 

Figure 4 shows a program that receives two integers 
as input , finds their minimum, calculates its factorial 
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if it is positive, and then saves the result in z. First, 
the verification conditions of the two while loop have 
to be checked. Hence, we let CARE-FSQ 2 print the 
composition [if B then S fi ] o / to assist us in this 
process. Before printing the results of the composi- 
tion, the user is prompted to enter his simplifications 
for some expressions if he/she desires(see figures 5 and 
6 ). 

Since the three verification conditions are satisfied 
for both loops, we can therefore proceed to find the 
functional meaning of the whole program which is 
shown in figure 7. 

The symbolic execution result is z 

-mln<x,y> < O -> 

x r y, z, xl + yl« b : = 
x 0 y „ GAMMfHroin<x,y>-*-l> , rnin(x,y>, 
mln(x,y>, 0*. GAMhA<min<x,y >+l> 

I 

min(x,y) <= 0 -> 

x# y » z *• xl *> yl # b *- 

x*. y., 1*> min<x*y>* mlr»<x,y>^ mln<x,y), 1 
Figure 7: Specification of the whole program. 


5 Conclusion 

In this paper, we have presented a process model 
for extracting reusable components. It first identifies 
these components using software metrics, then it qual- 
ifies them. We have focused on the qualification phase 
which generates their formal specifications, generates 
a significant set of test cases, and packages them for 
future reuse. We have then described the specifica- 
tion tool of the qualification phase, CARE-FSQ 2 , that 
helps in understanding programs by generating their 
correct formal specifications. Further research needs 
to be done in order to be able to qualify and tailor 
large programs for reuse. 
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